Computers are being used today to perform a wide variety of tasks. Many different areas of business, industry, government, education, entertainment, and most recently, the home, are tapping into the enormous and rapidly growing list of applications developed for today's increasingly powerful computer devices. Computers have also become a key technology for communicating ideas, data, and trends between and among business professionals. These devices have become so useful and ubiquitous, it would be hard to imagine today's society functioning without them.
Computers operate by executing programs, or a series of instructions, stored in a memory. These programs and series of instructions are collectively referred to as software. Software is what makes computer systems function and perform useful tasks. The utility of a computer system often hinges upon the speed and efficiency with which the computer executes the software program. Hence, it is desirable that the processor of the computer execute software programs as fast as possible. As the processor executes a program, there may be several significant events occurring in the computer's peripheral system hardware. It is often necessary to signal the processor to respond to an external condition, even though the processor is executing a program. This signaling process is referred to as an interrupt.
Interrupts are changes in the flow of software execution not caused by the currently running program. Some other process, usually input or output related, is responsible for the change in the flow of execution. For example, a program may instruct a hard disk coupled to the computer system to begin a data transfer, and configure the hard disk to provide an interrupt as soon as the data transfer is complete. The interrupt stops the currently executing program and transfers control to an interrupt service routine (ISR) which performs some appropriate action. When finished, the ISR returns control of the processor to the interrupted program. The processor subsequently restarts the interrupted program in the same state it was in when the interrupt occurred.
The need for interrupts arise from the fact that, in most cases, input and output (IO) can proceed in parallel with processor execution. On computers where the processor issues an IO instruction and then stops to wait for the IO to be completed, there is no need for an interrupt. When the IO is finished, the processor is restarted at the instruction following the IO instruction. Because the processor can generally execute many hundreds of thousands, or even millions, of instructions during the time required to complete a single IO instruction, it is very wasteful to force the processor to be idle during this time. Interrupts and interrupt subsystems allow the processor to execute the program concurrently with the IO and be signaled as soon as the IO is completed.
Prior art FIG. 1 shows a flow chart of the basic steps of a prior art interrupt service process 100 for industry standard architecture (ISA) computer systems. As discussed above, an interrupt causes the processor to temporarily suspend execution of the current program and forces it to jump to the ISR. Process 100 shows the steps a processor performs in servicing an interrupt.
In step 10, the processor detects an interrupt request. The processor, in ISA bus based computer systems, has one interrupt request input that is used to detect interrupt requests. The interrupt request lines from the various IO devices are not coupled directly to the processor's interrupt request input, rather, the processor's one interrupt request input is coupled to a programmable interrupt controller (PIC) which, in turn, is coupled to as many as eight peripheral devices. The peripheral devices signal interrupt requests via the PIC.
In step 11, the processor responds to the interrupt request by generating an interrupt acknowledge. During the interrupt acknowledge, the processor determines which device requested the interrupt and fetches the address of the appropriate ISR. As discussed above, the ISR performs the appropriate action to service the interrupt.
In step 12, the program pointers and other information for the program currently executing are "pushed" onto the processor's stack. This allows the state of the currently executing program to be saved while the processor executes the ISR.
Next, in step 13, the processor jumps to the address of the appropriate ISR and begins executing it. The ISR subsequently services the interrupt. At this point, the processor executes the software of ISR, performing the tasks required to service the interrupt.
In step 14, the processor "returns" from the ISR. Each ISR ends with a return-from-interrupt instruction. When execution of the ISR is complete, the processor executes the return-from-interrupt instruction which automatically "pops" the program pointers and program information off of the processor's stack.
Thus, in step 15, the processor can continue execution of the interrupted program. The processor restarts execution in the same state the program was in prior to interruption.
In ISA bus computer systems, process 100 is implemented in an event based interrupt system. That is, an interrupt is a specific event which occurs and is detected by the computer system. In ISA bus systems, the interrupt request line coupled to the PIC is driven low and then either pulled up by a pull up resistor coupled to the interrupt request line or driven back up by the interrupting device (i.e., the source). The rising edge of the interrupt request line is detected by the PIC as an interrupt request. Thus, in ISA bus computer systems, the interrupt request line is "strobed." In such a system, the strobe constitutes an event, and the event is recognized as an interrupt request.
In newer, PCI (peripheral component interconnect) bus computer systems, however, the process 100 is implemented in a level, or state based, interrupt system. The steps of the process 100 are basically the same but the interrupt system is different. In PCI bus based computer systems, an interrupt is a state which is entered. The interrupt request line is driven low and kept low. The interrupt request line is coupled usually coupled to a programmable interrupt router (PIR) as opposed to a PIC. The PIR detects the low level as the interrupt request. The interrupt request line remains asserted until the source of the interrupt is serviced.
Newer computer systems are built around the PCI bus and utilize peripheral devices based on the PCI bus for much of their functionality. Accordingly, many computer system manufacturers are reusing older hardware designs and adapting older software applications to function on or within PCI bus based devices. However, many of the older hardware devices and software applications are intimately designed to the specific characteristics of the ISA bus. For example, many popular "legacy" software applications do not know how to interface with PCI bus based peripheral devices. Hence, these legacy software applications do not properly interface with the PCI bus environment. More particularly, the ISRs in the legacy applications were designed for the specific requirements of the ISA bus, not the PCI bus.
For example, audio peripheral devices (e.g., wave table sound boards) and other types of ISA peripheral devices utilize the ISA architecture interrupt system. One characteristic of the ISA architecture is that once an interrupt occurs, other interrupts can be masked and not recognized until the end of the current interrupt. This prevents a large number of interrupts from piling up, or "nesting". Some legacy applications allow the nesting of interrupts. They allow the interrupt service routine from one interrupt to be interrupted by another interrupt service routine. This is the case with software applications dealing with, time sensitive input and output, such as real time simulations using the audio peripheral device for example. In such an application, the nesting of interrupts help make the computer system more responsive to the user.
Thus, with reference still to prior art FIG. 1, when an interrupt is detected as in step 10, the computer system proceeds through steps 11, 12, and 13 in the manner described above. Once the ISR from the legacy application is started in step 13, it checks to see if there is another interrupt. If another interrupt is detected, steps 10 through 13 are again repeated, hence, nesting the interrupts. The nested interrupts are completed, one by one, until step 15 is reached from the original (i.e., the first to occur) interrupt and the legacy application can continue.
In the ISA bus, the interrupt request line returns to a deasserted state (i.e., a high level) immediately after the event (i.e., the strobe). Thus, in computer systems having an ISA bus, the ISR does not detect its own interrupt due to the fact that the interrupts are strobes. The event occurs and then goes away automatically. The strobe is latched by the PIC and the interrupt request line subsequently returns to normal.
In PCI bus based computer systems, however, the interrupt request line is asserted low, and typically remains low until the source is serviced. Thus, when the legacy application ISR checks for another interrupt in step 13, it detects its own interrupt state signal since it was never removed. The legacy ISR then erroneously concludes that there is another interrupt, and the system subsequently executes steps 10 through 13 again. This fetches the same ISR again, which executes the same instructions again, which detects itself as another interrupt. The loop continues until the stack over flows, crashing the computer system.
Hence, legacy applications do not know how to interface with the PCI bus environment's state based interrupt system. When a legacy ISR checks to see if there is another interrupt without clearing its own interrupt, it detects its own interrupt as a "new" interrupt. This same scenario keeps happening, repeating itself until the system crashes. It is expected, however, that these legacy applications be supported by the newer computer systems. The newer computer systems are expected to run the great majority of the legacy applications.
Additionally, many older hardware designs are being incorporated into PCI bus based devices. Newer systems increasingly rely on the more modern PCI bus for IO. Consequently, many commonly used preexisting ISA bus based designs are being incorporated into modern PCI bus based IO devices. Often, these preexisting ISA bus based designs do not interface properly with the PCI bus environment's state based interrupt system.
Therefore, what is required is a system for accommodating legacy software applications in PCI bus based computer systems. What is further desired is a system which ensures preexisting ISA bus based designs properly interface with the PCI bus environment's state based interrupt system. The required solution should not require extensive reworking of legacy software applications or preexisting ISA bus based designs. The required solution should be transparent to both.